How to communicate errors 如何傳達錯誤資訊
為什麼現在很多軟體的錯誤提示根本沒考慮使用者體驗。
因為程式設計師會經常對設計師說：“還有這個情況，也得加個錯誤提示”這樣會導致錯誤提示都是程式設計師說的，但程式設計師並不是使用者。所以即使大廠的產品錯誤資訊使用者體驗也不好。
為什麼程式設計師和使用者差別很大
剛寫東西停頓一下，就跳出"需要空格"的報錯，甚至下一行也莫名報錯。程式設計師已習慣忽略紅色、黃色的各種提示，對硬體或第三方庫的錯誤也不在意。
總之，程式設計師對錯誤提示司空見慣
而使用者則對最小的錯誤也會感到緊張。錯誤多的時候使用者就擺爛了
Yahoo 的表單互動設計做得很糟糕
缺點：
1 使用者點了「繼續」，頁面瞬間一大片紅字跳出來。
更好的做法：
只提示使用者剛剛互動過的那個欄位，或者只提示第一個出錯的欄位，其餘先不管。
或者 配合輕微動畫（如按鈕晃動、欄位邊框閃一下）告訴使用者“這兒需要你注意”。
2 使用者只是在輸入「姓氏」時按了“繼續”，結果所有欄位，包括還沒點過的「出生日期」也全都報錯。
更好的做法：
把“錯誤提示”延遲到使用者真正填寫並離開欄位後再出現。
剛進入頁面時，表單可以不提示只在使用者真的操作過後再反饋。
Amazon做的有優點也有缺點
優點：
點“Continue”按鈕不會一開始就禁用。使用者不會一來就被“限制行為
開啟頁面後，遊標自動聚焦到第一個欄位，可以馬上開始輸入。
只要使用者在某個欄位輸入了內容並離開，錯誤提示就消失了。
當使用者填好當前欄位，按“Continue”後，系統自動幫使用者跳轉到下一個需要改的地方。
缺點：
1 所有欄位同時標紅，沒有優先順序。
更好的做法：
只標紅第一個有問題的欄位，其他的保持中性。
顯示一個友好提示，比如：“請先填寫你的名字”
按“繼續”後，自動聚焦到那個欄位，引導使用者直接開始改。
後續點選“繼續”後，依次校驗下一個欄位。
2 確認密碼欄位不提示錯誤，卻是必填項
更好的做法：
一開始就在欄位下方輕描淡寫地提示：“請重複輸入密碼以確認”
如果使用者跳過不填，按鈕點選後欄位才出現紅色提示
當使用者填完密碼欄位後，確認密碼欄位才變為“必填狀態”
3 從使用者角度看，“系統到底憑什麼這麼提示我？” 系統行為像“黑箱”。
更好的做法：
出現錯誤時，不要只顯示“錯誤”，而是說清楚“哪裡錯了”（例：“請輸入至少6個字元”）
使用者改錯後，立刻取消提示，並展示“已透過 ✓”
IBM 看上去整潔，但比Yahoo還差
優點：
1 按鈕預設是可點的
2 自動滾動到出錯欄位，但當使用者提交出錯後，頁面會自動滾動到第一個出錯欄位的位置。
缺點：
1 出現錯誤後，即使使用者刪除內容、清空欄位，表單也無法“回到乾淨的初始狀態”。嚴重違反了“可逆性（reversibility）”原則。
更好的做法：
使用者改完就清除紅框，恢復“初始狀態感”，讓人感覺“自己修對了”。
減少顏色強度或換成非“懲罰性”表達方式，例如：用「淡紅框 + 小字說明」，代替「濃烈紅框 +大段錯誤字串」。
首次進入頁面時就明確告訴使用者哪些是必填欄位。
2 不立即告訴使用者哪錯了，而是等使用者全部完成錯誤提示一起出現了
更好的做法：
錯誤提示逐步出現，不要一次性炸出來，比如先提示 email 再提示名字。
Google 表單錯誤
缺點：
1. 驗證時機過早，打斷使用者輸入流程。使用者還在輸入年份時就被提示錯誤，極其打擊使用者信心，形成所謂的“輸入焦慮”。
更好的方案：不要在使用者還沒輸完的時候就提示錯誤，應等使用者“離開欄位”後再判斷
2 提示方式粗暴且分散。就像早期 DOS 命令列系統那樣，直接把錯誤“扔”到螢幕上，只不過換成了 GUI、加了點紅色。
更好的方案：提前告訴使用者格式，比如：MM/YYYY格式說明放在輸入框下方，明確格式：例如：2022
正確的設計思路：
1 別把“使用者輸錯”和“系統沒找到”混為一談。
Process error（過程錯誤）：做某件事失敗了
Data error（資料錯誤）：你填的內容就不對
| 錯誤型別 | 舉例 | 正確反饋方式 |
|---|---|---|
| 資料錯誤（data error） | 郵箱缺了“@” | 用紅色 + 明確說明 “請輸入有效郵箱地址” |
| 過程錯誤（process error） | 郵件提交後返回失敗 | 用灰色、彈窗或頂部提示 “伺服器響應失敗，請稍後重試” |
| 資料錯誤 | ZIP code 少了數字 | 紅框 + 下方提示 “請輸入5位郵編” |
| 過程錯誤 | ZIP code格式正確但查不到結果 | 溫和提示 “我們暫未支援該區域” |
2 Empty field 空欄位 ≠ 錯誤
使用者沒填內容，不代表他錯了。只是還沒填而已。不要一上來就把空欄位標成紅色，給使用者一種“你已經做錯了”的感覺。
3 State change 狀態變化 ≠ 資料錯誤
電水壺燒開後會自動“跳閘”，但跳閘是由溫度感測器控制的，不是水本身控制的。不要懲罰使用者的空白和系統自己的錯誤。UI 的錯誤提示應該準確反映“錯的是誰”。
比如使用者輸入了郵編，點“搜尋”系統後臺沒找到匹配的城市，UI 卻把輸入框標紅，提示“格式錯誤”或“無效郵編”這會讓使用者產生錯誤歸因，以為自己輸錯了，其實是系統後臺的問題。應該是
| 型別 | 處理方式 |
|---|---|
| 使用者真的輸錯（data error） | 用紅色、明確提示（如缺少“@”） |
| 系統查不到（process error） | 用灰色/輕提示，例如“我們暫時找不到相關城市，可稍後再試” |
| 輸入還未開始 | 使用 placeholder 提示格式 |
發散方案：一次只讓使用者做一件事（One action at a time）
傳統表單設計的問題：
- 太多輸入框堆在一個頁面裡，使用者不知道從哪裡開始
- 錯誤一多，頁面瞬間變紅，使用者心理壓力大
- 想跳過？結果系統爆紅提醒“這裡也沒填、那也不對”
“每次只讓使用者面對一個欄位” + “系統用溫和方式提醒錯誤”
一個新表單原型測試表明每屏只放一個輸入框，測試給17個使用者用，比原表單快了13%！證明瞭使用者“每次只看一個輸入框”效率更高、出錯更少。demo:interactive prototype
| 藍色深淺 | 對應模組 |
|---|---|
| 深藍色 | 填姓名/郵箱/電話（ФИО...） |
| 中藍色 | 同意條款（Соглашения） |
| 淺藍色 | 輸入驗證碼（SMS） |
| 指標 | 表現 |
|---|---|
| 單欄位分屏互動是否更快？ | 是，大部分使用者在 30~70 秒內完成 |
| 哪些步驟容易拖慢節奏？ | 驗證碼（SMS） 和 填基本資訊 |
| 一次一個輸入項是否影響效率？ | 沒有變慢，反而提高了專注和成功率 |
| 設計原則 | 做法 | 好處 |
|---|---|---|
| 一次一個輸入項 | 每屏只放一個欄位 | 減少認知負擔，避免混亂和錯誤 |
| 無輸入 = 不推進 | 不跳轉下一步，但不爆紅 | 使用者自然意識到需要填寫 |
| 錯誤提示溫和引導 | “欄位未填”→ 自動跳焦點 + 灰色提醒 | 無需懲罰式紅字也能糾正行為 |
| 特殊場景相容 | 多欄位介面也可用“優先焦點+灰色提示”策略 | 保持體驗一致性 |
發散思考：用狀態管理器（State Manager）統一管理表單行為
| 功能 | 使用者體驗提升點 |
|---|---|
| 檢查所有欄位的狀態 | 找出第一個出錯的欄位，而不是一股腦報錯 |
| 自動帶使用者回到那個欄位 | 避免“你錯了但不知道錯在哪” |
| 在“Continue”按鈕上動態顯示欄位名 | 形成按鈕與欄位的視覺+語義連線 |
| 滑鼠懸停或鍵盤“Next”時給出溫和提示 | 替代紅色“嚴厲警告” |
左圖：
- 按鈕顯示「Continue」
- 使用者還有一個欄位（Street）沒填，但按鈕尚未互動觸發
右圖：
- 使用者滑鼠懸停或點選按鈕（但未填完整欄位）
- 按鈕內容變成「Enter street」，明確告訴使用者下一個該填哪個欄位
- 沒有用紅字！而是透過按鈕變化給出輕引導
傳統表單設計的問題，不是出錯，而是“錯誤反饋方式太糟糕”。狀態管理器的價值在於：
- 把「錯誤提示」變成「溫和引導」
- 把「批次報錯」變成「按時反饋」
- 讓使用者在互動過程中擁有“方向感”和“安全感”